Embodiments of the present invention relate to computer systems hat accomplish distributed processing with shared objects, and to methods of installing and maintaining distributed processing programs.
A distributed application program is a set of member programs written for cooperation on a network of computers. Each computer is a node of the network. Each member generally operates on a physically separate node and communicates with other members of the set to accomplish a distributed processing objective. Examples of such objectives include sharing information, sharing access to a peripheral input or output device, and sharing other services.
The basic unit of information storage is the computer file and, for executable information, the program object. To share information, a conventional service at a minimum employs a naming convention for files, accesses a file by its name, and makes a copy of the contents of the file onto a destination node for efficient use (e.g., reading and writing) by the member at a requesting node. While an application program may exist as a file or group of files, such a program in operation may be better understood as a process involving a collection (or set) of objects, each object being able to communicate with other objects by sending and receiving messages and able to perform requested services (i.e., operations). An object may control access or use of data by, for example, providing a limited number of standard operations on the data. Sharing a service is conventionally accomplished either by copying the requisite program files to the requesting node, or by employing a naming convention (e.g., an application program interface) and communicating messages (i.e., passing parameters and results) with objects of the member programs that make up the service.
As an example of a computer system with multiple services, consider a conventional office computer system for word processing. Each word processing application program may require a discovery service to locate printers it can use. Because the number and types of printers in an office computer system is subject to change, a word processing application program may call the discovery service to obtain current information about printers. When the discovery service searches the network to identify printers, the discovery service uses a significant portion of the computer network capability, perhaps slowing other users"" access to files on networked disk drives. To prohibit nonessential network traffic related to each word processor""s request for discovery, a system manager may locate the discovery service on only one computer of the network and require each word processing application program to call the same discovery service. This one discovery service is then able to search for printers, perhaps once per day, storing the search results and then respond to all requests for discovery with the result of the daily search; as opposed to performing a search in response to each separate request for discovery.
Communication between objects (e.g., an object of a word processing application program and an object of a discovery service) may be obtained using the industry standard Common Object Request Broker Architecture (CORBA). The structure and operation of CORBA and its components is described in xe2x80x9cThe Common Object Request Broker:
Architecture and Specificationxe2x80x9d and references cited therein all of which are incorporated herein by reference. Such an architecture may include a naming service. The naming service includes a database that associates an object name and a corresponding object reference. Each object desiring communication with another object calls the naming service, passing to it a name of the desired object. For example, when a word processor application program having a printer object desires to communicate with a reporting object of a discovery service, the printer object calls the naming service and passes the name of the reporting object. The naming service returns to the printer object an object reference to the reporting object. The object reference may then be used in subsequent communication.
Distributed application programs based on CORBA are conventionally implemented according to design rules that may complicate installation and maintenance. For example, such an application program is expected to be able to contact the CORBA object request broker (ORB) to obtain access to a shared object. The distributed application program must be installed and maintained to account for the cases when the ORB is completely unavailable and when service by the ORB is likely to be inefficient from a system operations standpoint. Information to intelligently handle these cases is generally unavailable to the programmer who develops the application program. Programmers conventionally assume that the ORB is available when the application program is executing; and, that the source code for the application program will be revised if systems efficiency becomes an issue. Application programs built on these assumptions may be impractical for mass marketing.
A distributed application program exhibits an object sharing strategy in the manner in which it was programmed to behave. When developing the application program, a programmer""s assumptions regarding object sharing constitute a sharing strategy. For example, the program may be written on the assumption that a particular object is shareable or may (at run time) determine whether a particular object is shareable. For each shareable object, the sharing strategy includes assumptions or determinations concerning: (a) whether the services and objects needed to permit sharing are actually available; (b) whether sharing will be accomplished through a CORBA ORB; (c) whether sharing will be accomplished in some other manner than a CORBA ORB; (d) whether similarly named objects are assumed not to exist, are expected to exist, or are to be discovered or confirmed by testing; (e) where similarly named objects are presently located; and (f) which of several similarly named objects is to be used. When developing a service for multiple computing environments, program complexity increases dramatically as the sharing strategy becomes more sophisticated.
In many cases, placing the intelligence to revise object sharing strategies in each application program wastes system resources. For example, when each application program must contain the logic for determining a sharing strategy for efficient network operation, the network overhead involved in cooperating with the network server to make an efficiency determination may consume the efficiency expected to be gained.
A system manager may not be able to revise the sharing strategy implemented by the programmer. Inconsistent sharing strategies of several application programs may interfere with installation or concurrent use of such application programs. If a system manager determines that network utilization would improve if object sharing were revised, the system manager may be faced with reprogramming each service that uses the particular shared object. In complex systems this approach to improved network efficiency may be cost prohibitive.
Another conventional approach is to expect the user to maintain object sharing strategies. A CORBA based service cannot expect the user to supply or maintain object sharing strategies because the user may be unaware that shareable objects have been installed, relocated, or deleted. The user may be unaware and unable to verify that greater system operating efficiency may result when an object is shared with or without using the CORBA ORB.
When, for example, a new word processor is to be added to the computer system described above, the word processor may fail because objects on remote nodes were not found and used. At the time of installation, it may be impossible to specify in advance an appropriate object sharing strategy. Because neither an application program developer (a programmer), nor a system manager, nor a skilled user may be available to determine an appropriate initial strategy or to revise the strategy in response to other system modifications over time, the computer system and/or the new application program may not perform as expected. Without a way to overcome these difficulties, computer systems that accomplish distributed processing with shared objects may not find wide acceptance by unskilled users and such systems and application programs may not be economially provided through mass marketing channels.
A memory, according to various aspects of the present invention, includes indicia of a method for providing an object reference in response to a request. The request originates on a first workstation and includes a first object identifier. The method includes the following steps in any order: (a) determining a policy in accordance with the first object identifier; (b) determining a selected object reference in accordance with the policy, wherein the policy governs selection between first indicia of a first object that would, if selected, execute on the first workstation and second indicia of a second object that would, if selected, execute on a second workstation; and (c) providing the selected reference.
According to various aspects of such a memory, operation of a computer system in accordance with the method provides several benefits. A system manager may revise the policy without having to revise the underlying program that made the request for an object identifier. Further, the policy so maintained by the system manager may differ from what could have been anticipated by the programmer of the underlying program that made the request. Examples of a few policies that may be implemented by the system manager include a policy that may dictate use of an object on the same workstation from which the request was made, dictate use of an object on a different workstation than the workstation from which the request was made, or dictate use of the latest revision of the object when more than one object having the same identity exists on the computer system.
According to other aspects of the invention described above, the underlying program is freed from responsibility for efficient operation in a wide variety of difficult to resolve conflicts. Conflict resolution in these matters complicates development and maintenance of such programs. For example, the underlying program that relies on the method described above for returning a reference to an object does not need to determine whether the requested object is shared, determine whether a port exists for object sharing, manage its own network utilization for system level efficiencies, resolve name conflicts when the requested named object exists in several versions throughout the computer system, or permit or facilitate revision of the underlying program to improve system operation. These benefits may permit development and maintenance of fewer versions of the underlying program with further economies of scale.
A memory in another variation according to various aspects of the present invention includes indicia of a method for installing an application program on a workstation. Such a method includes the following steps in any order: (a) installing a naming service on the workstation; (b) forming a registry for use by the naming service, the registry including an object identifier and a policy; and (c) installing the application program for execution at least in part on the workstation so that the application program makes a request to the naming service to obtain the object reference in accordance with the policy. The policy governs selection between indicia of a first object that would, if selected, execute on the workstation and indicia of a second object that would, if selected execute on a different workstation.
By installing the application program on the workstation in the manner described above, the application program may be delivered without all of its component members. These omitted components may be requested using the naming service and coupled to the application program for use by the application program as shared objects. By referring to the policy, these shared objects may include objects able to be activated on the same workstation that the application program is being installed upon, or objects able to be activated on remote portions of a computer system of which the workstation is a part. Further, by separating the policy from the application program, an originally suggested policy may be overridden by a current or future policy set by a system manager as opposed to being specified by the developer or the maintainer of the application program.
A data structure according to various aspects of the present invention includes an object identifier and a policy for determining whether an object reference is to be returned in response to a request. Such a request includes a second object identifier corresponding to the object identifier found in the data structure.
By including the policy in the data structure, as opposed to implementing the policy as design assumptions in the application program that would be requesting the object, revision of the policy is greatly simplified. Further, when a large number of data structures of the type described above exist on a computer system, revisions of such data structures for consistency and for efficient operation of the computer system may be made with far less effort than revising the implementations of such policies in the many services able to be activated on the computer system.